Embedded systems can be common in consumer electronics (see, e.g., References 1-4), automotive and industrial control systems (see, e.g., References 5-7), and sensor networks. (See, e.g., Reference 8). The hardware of an embedded system can be a low-cost system-on-chip (SoC) that can use intellectual property (“IP”) cores such as processors, input/output (“I/O”) peripherals, memory components, and system-specific IP such as sensors (see, e.g., Reference 4), Wi-Fi (see, e.g., Reference 8), Bluetooth (see, e.g., Reference 6), etc. A system bus can integrate the IP cores for communication. However, the system bus can expose the embedded system to two classes of attacks.
Hijacking (see, e.g., Reference 9): the bus can be used to write to the restricted memory to take control of the system. Previous disclosures describe how the Universal Serial Bus (“USB”) port of a learning thermostat can be used to load arbitrary code to local random access memory (“RAM”) via the shared system bus. (See, e.g., Reference 1). In such example, an external device was connected to the Universal Asynchronous Receiver Transmitter (“UART”) port of a mobile router. (See, e.g., Reference 3). The device automatically was granted write access to system memory over the bus. An attacker can leverage this access to control the wireless network.
Extraction (see, e.g., Reference 9): here the attacker can use the bus to read restricted memory, and leak sensitive data from the system. Malicious firmware can be embedded in systems for cars, and can use the bus leak data such as private conversations and geolocation. (See, e.g., References 6 and 10). Malicious firmware in medical devices can be used to access the bus to leak boot loader code from the read only memory (“ROM”), exposing sensitive data such as secret keys. (See, e.g., Reference 11).
One way to thwart hijacking and extraction attacks can be with a security countermeasure that can define and enforce the embedded system's memory access control policy. (See, e.g., References 10 and 11). For each IP that accesses memory (e.g., bus master), the embedded system engineer can specify its read and write access rights to each memory segment (e.g., bus slave). A software or hardware mechanism can monitor memory accesses to enforce the policy.
Countermeasures Against Hijacking and Extraction
Segmentation and paging can be commonly used to enforce memory access control policies in desktops, laptops, smartphones, and tablets. (See, e.g., Reference 12). In these approaches, Memory Management Unit (“MMU”) and I/O-MMU can be used to enforce the defined policy. The MMU can incur area and power overheads that may not be acceptable in low-cost embedded systems. (See, e.g., Reference 13).
The Memory Protection Unit (“MPU”) can be a lightweight MMU for advanced RISC Machine (“ARM”) processors used in embedded systems. (See, e.g., Reference 14). The MPU may only detect attacks by the processor, and may not be able to monitor other bus masters that have Direct Memory Access (“DMA”). The MPU can be used to monitor all bus masters of the SoC. (See, e.g., Reference 15). This MPU design can incur about a 25% area overhead for a MicroBlaze processor (see, e.g., Reference 16), and thus cannot scale to embedded systems.
ARM TrustZone is a software-hardware architecture for memory protection in embedded systems. (See, e.g., Reference 17). To be compatible with ARM TrustZone, the IP cores should be enhanced with security features only available in ARM cores. This can limit which IP vendors the embedded system engineer can use.
The bus decoder can be augmented with registers to define restricted memory ranges. (See, e.g., References 18). When a bus master makes a memory access, the decoder can verify the address against the restricted range to detect an attack. This approach can decrease the maximum bus frequency by about 26%; a significant performance overhead compared to execution without the modified decoder.
Approaches that provide isolated software execution on embedded systems (see, e.g., References 19-21) can also enforce the memory access control policy. These mechanisms can be limited to the processor, but may not be able to detect attacks by DMA-capable bus masters. Moreover, they can make modifications to the internal logic of the processor. This needs re-validation of the modified IP cores, which the delays time-to-market of the system. Software countermeasures can add run-time checks to firmware code to monitor memory accesses. (See, e.g., References 22 and 23). Such approaches need the embedded system to host a real-time operating system (“RTOS”) to process the checks against the memory access control policy.
Thus, it may be beneficial to provide exemplary system, method, and computer-accessible medium for low-overhead security wrapper for memory access control of embedded systems, which can overcome at least some of the deficiencies described herein above.